I don't think this structure precludes anything I'm about to say. I'm just writing a note as I think about this.

We've talked about stacking multiple versioned corpuses so each TUF repo doesn't need to include the measurements for all versions. This would allow us to check for version N and N-1 measurement values without having to put both of them in one TUF repo. However, for installinator, for a mupdate of a single sled on an existing rack, we'd probably want to be able to include the last few versions of measurements in a TUF repo or have some other way to stack when doing a fresh install. The problem with the former is that we won't always require strict release upgrading from version N-1 to N in the future. The problem with the latter is we now need to be able to source the different manifests from wicket.

Including previous versions of measurements in a TUF repo would get a little tricky and require some manual hand holding unless our automation gets a lot smarter. What I was planning to do is rotate the measurements from INSTALL to CLUSTER after an initial boot/attestation and have a set of all available measurements. I started trying to do that here but I struggled with finding a good spot to do the rotation.

Do we want to ignore an error if this path already exists? Should we have a delete step, since this is a "mupdate"?

Good suggestion on ignoring the error. The delete step should be covered by code further up the file where we clean everything out on install.